What about passing in formatting options. That is, turn this into:

func FromCid(c cid.Cid, options ...CidFormatOption)

(or something like that)

Yes, it'll probably be slightly more complicated but its extensible and nicer for the user. I can then, e.g., write FromCid(c, CidBase(someMultibase), ...). Thoughts?

Basically, forcing users to pass a CID "transformer" in on every call to FromCid is just kind of icky.

In my view this is not the place for complicated option parsing as that should be done higher up. The idea is we set a single value in the context (using context.WithValue) higher up and then get the value from the context using cidenc.Get(ctx) (see ipfs/go-cidutil#8).

Part of the reason I took in a simple function (rather than say an interface) is to avoid a circular decency with go-cidutil that will be introduced once ipfs/go-cidutil#8 is merged.

Or to put it another way the idea is to use the cidenc package (from ipfs/go-cidutil#8) to construct an encoder and then pass that to FromCid. This encoder will often be constructed higher up and stashed into the context. I would take an interface but depending on cidenc will create a circular decency that needs to be resolved somehow. (The cidenc package has a utility function that parses a path for a Cid in order to set default paramaters based on an existing Cid or path, which is used by ipfs resolve to fix ipfs/kubo#5234).